Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming

ABSTRACT

A method of signaling and negotiation between a client and a server in a multimedia streaming service regarding the adaptation of the data delivery process. In order to make sure that the client supports the adaptation mechanisms or capabilities to be used in data delivery, one of the parties provides information indicating the adaptation mechanism or capability that it supports to the other party. Upon receiving the information, the other party uses well-defined RTSP response to indicate the support of that mechanism or capability. Either the server or the client can initiate the negotiation. The implementation of the signaling and negotiation covers an AVPF usage, RTP Retransmission Playload Format usage, and an SPTP usage in a particular 3G PSS session.

[0001] This patent application is based on and claims priority to U.S.Provisional Applications No. 60/447,264, filed Feb. 13, 2003; No.60/448,309, filed Feb. 14, 2003; No. 60/448,284, filed Feb. 14, 2003 andNo. 60/448,299, filed Feb. 14, 2003.

CROSS REFERENCES TO RELATED PATENT APPLICATIONS

[0002] This patent application is related to U.S. Patent Applications,Docket No. 944-001.103-4, and Docket No. 944-001.103-6, both assigned tothe assignee of the present patent application and filed on even dateherewith.

FIELD OF THE INVENTION

[0003] The present invention relates generally to multimedia streamingand, more particularly, to signaling of streaming quality adaptation andcontrol mechanism.

BACKGROUND OF THE INVENTION

[0004] In a multimedia streaming service, there are three participantsinvolved: a streaming server, a streaming client and an underlyingnetwork which provides the connectivity between the server and theclient. The server provides the functionality to deliver the multimediastreaming content to the client. For that purpose, the client and servercommunicate with each other over the network regarding the methods ofcapability exchange, content delivery method negotiation, contentdelivery control, and so forth. Such information exchange can be carriedout via well-defined network protocols.

[0005] For a multimedia streaming session to be set up and startedsuccessfully, the server and the client need to support a minimal set ofprotocols, which are selected as standard protocols by the service. Anexample of such a service can be found in 3GPP TS 26.234 V5.1.0,“Transparent End-to-End Packet Switched Streaming Service (PSS);Protocols and Codecs (Release 5)”, June 2002, hereafter referred to asTS 26.234). Furthermore, in order for a service to be successful fromthe data delivery and playback performance point of view, the datadelivery control mechanisms in the service must also be well-defined.Such mechanisms are used to adapt the data delivery process in order tocause the changes of behavior in the underlying network characteristics.

[0006] Three possible adaptation processes based on the decisive controllocation of the adaptation mechanisms or capabilities are as follows:

[0007] Client-Driven Adaptation

[0008] The client has control of the adaptation functionality orcapability and makes the necessary decisions for adaptation. Thedecisions are based on information gathered from the network, theserver, or other sources of information within the service definition.

[0009] Server-Driven Adaptation

[0010] The server has control of the adaptation functionality orcapability and makes the necessary decisions for adaptation. Thedecisions are based on information gathered from the network, theclient, or other sources of information within the service definition.

[0011] Cooperative Adaptation

[0012] Control of the adaptation functionality or capability isdistributed between the server and the client. Both the server and theclient can take actions for adaptation based on the information gatheredfrom the network, the server, the client, or other sources ofinformation within the service definition.

[0013] Within the service context, there may be more than one adaptationmechanism or capability defined within the context of each of theabove-mentioned adaptation processes. It may be the case that each ofthese adaptation mechanisms or capabilities is standardized within theservice, but kept optional for a server or client to implement.

[0014] Therefore, there is a certain need for a capabilityidentification mechanism to identify the supported adaptation mechanismsor capabilities and an adaptation capability signaling and negotiationmechanism for the server and client to agree on the usage of aparticular set of adaptation mechanisms or capabilities defined withinthe service context.

[0015] In prior art, Annex G of 3G PSS (Rel.5) defines a signalingmechanism, which can be used to signal the usage and support parameters,but this is not a complete solution.

SUMMARY OF THE INVENTION

[0016] The present invention provides a method of signaling andnegotiation between a client and a server in a multimedia streamingservice regarding the adaptation of the data delivery process. Themethod can be carried out using a capability exchange mechanism, orusing a multimedia streaming control protocol. The method of signalingand negotiation, according to the present invention, can be implementedin AVPF (Extended RTP profile for PTCP-based feedback) usage in aparticular 3G PSS session; RTP retransmission payload format usage in aparticular 3G PSS session; and SRTP usage in a particular 3G PSSsession.

[0017] The method, according to the present invention, can be carriedout when the Multimedia Streaming Service has well-defined and/orstandardized adaptation processes, and each adaptation process iscomposed of well-defined and/or standardized mechanisms, which are toolsto render the adaptation functionality or capability functional.Furthermore, each adaptation mechanism or capability has an attributethat is well-defined and/or standardized within the service context, orwell-known between the server and the client.

[0018] Accordingly, the present invention provide a method for signalingand negotiation between a client and a server in a multimedia streamingservice, wherein a plurality of adaptation mechanisms or capabilitiesfor use in the service for data delivery are supported by the client,each adaptation mechanism or capability having an attribute. The methodcomprises:

[0019] the client providing information indicative of the attributesdefining the adaptation mechanisms or capabilities that are supported bythe client;

[0020] the server selecting one or more of the attributes based on theprovided information; and

[0021] the server providing further information indicative of theselected attributes so as to allow the client to know the one or moreadaptation mechanisms or capabilities defined by the one or moreattributes selected by the server.

[0022] According to the present invention, the client provides theinformation via a capability exchange mechanism, or via a multimediastreaming control protocol.

[0023] Alternatively, the method comprises:

[0024] providing by one of the two parties to the other of the twoparties information indicative of one or more attributes defining one ormore of the adaptation mechanisms or capabilities; and

[0025] conveying a message from said other party to said party, inresponse to the information, acknowledging supporting of said one ormore adaptation mechanisms or capabilities.

[0026] Either the client or the server can initiate the negotiation. Ifthe client initiates the negotiation, the client provides a plurality ofattributes to the server; and the server selects one or more of theprovided attributes based on the provided information for acknowledgingthe support.

BRIEF DESCRIPTION OF THE DRAWING

[0027]FIG. 1 shows a declaration by a client as part of the signalingand negotiation process, according to the present invention.

[0028]FIG. 2 shows the SDP description sent by the server to indicatethe selected attributes to the client, according to the presentinvention.

[0029]FIG. 3 shows the SDP description in an RTSP message sent by theserver.

[0030]FIG. 4 shows an RTSP DESCRIBE response sent by the server.

[0031]FIG. 5 shows a declaration by the client as part of the signalingand negotiation process, according to another embodiment of the presentinvention.

[0032]FIG. 6 shows the SDP description sent by the server to indicatethe selected attributes to the client, according to the other embodimentof the present invention.

[0033]FIG. 7 shows the SDP description in an RTSP message sent by theserver.

[0034]FIG. 8 shows an RTSP DESCRIBE response sent by the server.

[0035]FIG. 9 shows a declaration by the client as part of the signalingand negotiation process, according to yet another embodiment of thepresent invention.

[0036]FIG. 10 shows the SDP description sent by the server to indicatethe selected attributes to the client, according to the presentinvention.

[0037]FIG. 11 shows the SDP description in an RTSP message sent by theserver.

[0038]FIG. 12 shows an RTSP DESCRIBE response sent by the server.

[0039]FIG. 13 is a flowchart illustrating the method of signaling andnegotiation between a client and a server regarding the adaptation of adata delivery process, wherein the client initiates the negotiation.

[0040]FIG. 14 is a flowchart illustrating the method of signaling andnegotiation wherein the server initiates the negotiation.

DETAILED DESCRIPTION OF THE INVENTION

[0041] The method of signaling and negotiation between a client and aserver in a multimedia streaming service regarding the adaptation of thedata delivery process, according to the present invention, can becarried out via a capability exchange mechanism or via a multimediastream control protocol. The adaptation of the data delivery process isbased on one or more attributes of one or more adaptation mechanisms orcapabilities, which are used to determine the adaptation processes in aMultimedia Streaming Service.

[0042] When the signaling and negotiation is carried out via acapability exchange mechanism, the procedure is described as follows:

[0043] The client declares in its capability profile defined for acapability exchange mechanism the attributes of the adaptationmechanisms or capabilities implemented by the client;

[0044] The server obtains the capability profile;

[0045] As the server knows which adaptation mechanisms or capabilitiesare implemented by the client, the server selects a subset of theattributes that do not conflict with the adaptation processes. Accordingto the selected subset of attributes, the server tailors the multimediasession description and declares the session description to the client;and

[0046] Based on the session description, the client knows the adaptationmechanism or capability selection carried out by the server for theparticular multimedia session. The client accepts the adaptationmechanisms or capabilities declared in the session description bydefault, because the declared description contains a subset of theattributes or adaptation mechanism capabilities declared by the client.

[0047] When the signaling and negotiation is carried out via amultimedia streaming control protocol, the procedure is described asfollows:

[0048] The client includes the attributes of the adaptation mechanism orcapability implemented by the client in the Multimedia Streaming ControlProtocol defined for the control of the streaming session;

[0049] Based on those attributes, the server knows which adaptationmechanisms or capabilities are implemented or required by the client.The server selects a subset of attributes that do not conflict with theadaptation processes and signals to the client the selected ornon-selected attributes. Depending on the current phase of the controlcommunication, the server may tailor the multimedia session descriptionaccording to the selected attributes and declare the session descriptionto the client; and

[0050] Based on the response from the server, the client knows whichattributes are selected by the server. The client accepts by default theadaptation mechanisms or capabilities defined by the attributes selectedby the server, because the selected adaptation mechanisms orcapabilities are a subset of the adaptation mechanisms or capabilitiesdeclared by the client.

[0051] The method of signaling and negotiation, according to the presentinvention, can be implemented in the multimedia streaming service basedon TS 26.234 or later releases. The implementation covers thedefinition, signaling and negotiation of the following mechanisms:

[0052] an AVPF usage in a particular 3G PSS session (see, for example,IETF draft-ietf-avt-rtcp-feedback-04: “Extended RTP profile forRTCP-based Feedback (RTP/AVPF)”, Ott et al., 2002, hereafter referred toas draft-avpf-04);

[0053] an RTP Retransmission Payload Format usage in a particular 3G PSSsession (see, for example, IETF dradt-ietf-avt-rpt-retransmission-05:“RTP Retransmission Payload Format”, Rey et al., 2002, hereafterreferred to as draft-retransmission-05); and

[0054] an SPTP usage in a particular 3G PSS session (see, for example,IETF draft-ietf-avt-srtp-05: “The Secure Real-time Transport Protocol”,Baugher et al., 2002, hereafter referred to as draft-srtp-05).

[0055] I. AVPF Usage in a Particular 3G PSS Session

[0056] If AVPF, as defined in draft-avpf-04 is supported by the client,and the client signals the AVPF support, then the server may use anycombination of AVPF features as defined in draft-avpf-04 in theadaptation process. The client may also signal each supportable featureof AVPF (e.g., immediate feedback mode, early RTCP packet support, etc.)separately, if there's a well-defined mechanism identifier for thatfeature.

[0057] Let the attribute “AVPFSupport” be defined in the RDF (ResourceDescription Framework) Schema vocabulary to signal the support of AVPFdefined in draft-avpf-04 for audio and video media.

[0058] Let the attribute “UnSupportedAdaptationSupport” be defined inthe RDF Schema vocabulary as an adaptation mechanism or capability,which is supported by the client, but not by the server.

[0059] Let the attribute “SupportedAdaptationSupport” be defined in theRDF Schema vocabulary as an adaptation mechanism or capability, which isalso supported by the server.

[0060] Let “x-avpfsupport” be a well-defined SDP (Session DescriptionProtocol) attribute, which is included in the audio and video (or thesession-level for usage in both media types) media section of the SDPwhen AVPF is supported.

[0061] Let “x-unsupportedadaptationsupport” be a well-defined SDPattribute, which is included in the SDP (session or media level) whensupported.

[0062] Let “x-supportedadaptationsupport” be a well-defined SDPattribute, which is included in the SDP (session or media level) whensupported.

[0063] A. Signalling and Negotiation via a Possible Capacity ExchangeMechanism:

[0064] The client sends an RTSP DESCRIBE request to the server with aURI pointing to the client capability information residing in acapability exchange server.

[0065] The server fetches the capability declaration of the client fromthe capability exchange server. The declaration includes a part for theclient-side streaming capabilities, as shown in FIG. 1.

[0066] The bold lines in the declaration represent the adaptationmechanism support capabilities of the client. It should be noted thatwhen an attribute value is TRUE, the mechanism or capability issupported by the client. Conversely, when the attribute value is FALSE,the mechanism or capability is not supported by the client. For example,if the attribute AVPFSupport is TRUE, it declares that the client hasthe AVPF support for audio and video media components in a particularsession.

[0067] Seeing this capability, the server tailors the SDP description tobe sent to the client including the AVPF capability and theSupportedAdaptationSupport capability. The SDP description is shown inFIG. 2. The server does not include the SDP attributes based on theUnsupportedAdaptationSupport, because it does not have support for it.The bold lines in the SDP description indicate the usage of the AVPF andthe support for SupportedAdaptationSupport.

[0068] By receiving this SDP description, the client knows that AVPFwill be used for the video component, but not for the audio component.It is also possible that AVPF be used for both audio and video mediacomponents. In such a case, “a=x-avpfsupport” would be a session-levelSDP attribute. Client also understands that UnsupportedAptationSupportwill not be used and SupportedAdaptationSupport mechanism or capabilitywill be used for both audio and video media.

[0069] B. Signalling and Negotiation via a Possible Multimedia StreamingControl Protocol:

[0070] In 3G PSS, RTSP protocol is used to control the multimediasession.

[0071] Let “x-avpfsupport” be a well-defined RTSP option tag, whichindicates AVPF support on the client.

[0072] Let “x-unsupportedadaptationsupport” be a well-defined RTSPoption tag, which is signalled in the RTSP message when supported by theclient. It is assumed that the mechanism represented by this tag is notsupported by the server.

[0073] Let “x-supportedadaptationsupport” be a well-defined RTSP optiontag, which is signalled in the RTSP message when supported by theclient.

[0074] The client is assumed to know the RTSP URL for the multimediasession.

[0075] The client sends a DESCRIBE request with the selection ofpreferred adaptation mechanisms or capabilities:

[0076] Client->Server:

[0077] DESCRIBE rtsp://foo/twister RTSP/1.0

[0078] CSeq: 1

[0079] Require: x-avpfsupport, x-unsupportedadaptationsupport,x-supportedadaptationsupport

[0080] The client uses the RTSP Require request header to signal thesupported mechanisms or capabilities.

[0081] In order for the server to successfully tailor the SDP accordingto the mechanisms or capabilities supported by the client, the clientsignals the mechanisms or capabilities supported in an RTSP requestprior to or at RTSP DESCRIBE method.

[0082] The server checks the RTSP request and sees that it can usex-avpfsupport and x-supportedadaptationsupport, but notx-unsupportedadaptationsupport.

[0083] The server has two possible ways to respond:

[0084] Alternative 1:

[0085] Server sends an RTSP 551 “Option Not Supported” Response,including the unsupported mechanisms and capabilities in the messagebody:

[0086] Server->Client

[0087] RTSP/1.0 551 Option not supported

[0088] CSeq: 1

[0089] Unsupported: x-unsupportedadaptationsupport

[0090] Client issues another DESCRIBE request with only the supportedmechanisms or capabilities:

[0091] Client->Server:

[0092] DESCRIBE rtsp://foo/twister RTSP/1.0

[0093] CSeq: 2

[0094] Require: x-avpfsupport, x-supportedadaptationsupport

[0095] Server responds with an RTSP 200 OK message, also containing SDPdescription as shown in FIG. 3.

[0096] Alternative 2:

[0097] Server sends a RTSP DESCRIBE response, containing unsupportedmechanism/capability information without an RTSP 551 status response.The RTSP DESCRIBE response is shown in FIG. 4.

[0098] Server uses RTSP Unsupported response header to signal theunsupported mechanism or the adaptation mechanisms or capabilities thatare not possible to use for the particular session, and uses theappropriate SDP attributes to signal the usage of the selectedadaptation mechanisms or capabilities.

[0099] When the client receives the DESCRIBE response with the SDPdescription, it knows which set of adaptation mechanisms or capabilitiesare selected for usage in this particular session.

[0100] In the case that the client receives the SDP description fromanother source, e.g. via MMS, the client can analyze the SDP descriptionand find out the RTSP session URL. Then, it can send an RTSP DESCRIBErequest to signal and negotiate the adaptation mechanisms orcapabilities. The client can tailor the set of adaptation mechanisms orcapabilities by analyzing the MMS retrieved SDP description beforehand.This solves the confusion on the server side, because the server doesnot exactly know the content of the SDP description in such a usagescenario.

[0101] II. RTP Retransmission Payload Format Usage in a Particular 3GPSS Session

[0102] Let the attribute “RtxSupport” be defined in the RDF Schemavocabulary to signal the usage of the RTP retransmission mechanismdefined in draft-retransmission for audio and video media. RTX Supportis automatically defined AVPF support on the client side.

[0103] Let the attribute “UnSupportedAdaptationSupport” be defined inthe RDF Schema vocabulary as an adaptation mechanism or capability,which is not supported by the server, but the client.

[0104] Let the attribute “SupportedAdaptationSupport” be defined in theRDF Schema vocabulary as an adaptation mechanism or capability, which isalso supported by the server.

[0105] Let “x-rtxsupport” be a well-defined SDP attribute which isincluded in the audio and video (or the session-level for usage in bothmedia types) media section of the SDP when RTP retransmission payloadformat is supported.

[0106] Let “x-unsupportedadaptationsupport” be a well-defined SDPattribute which is included in the SDP (session or media level) whensupported.

[0107] Let “x-supportedadaptationsupport” be a well-defined SDPattribute which is included in the SDP (session or media level) whensupported.

[0108] A. Signalling and Negotiation via a Possible Capability ExchangeMechanism

[0109] The client sends an RTSP DESCRIBE request to the server with aURI pointing to the client capability information residing in acapability exchange server.

[0110] The server fetches the capability declaration of the client fromthe capability exchange server. The declaration includes a part for theclient-side streaming capabilities, as shown in FIG. 5.

[0111] The bold lines in the declaration represent the adaptationmechanism support capabilities of the client. RtxSupport, when TRUE,declares that the client has the RTP retransmission payload formatsupport for audio and video media components in a particular session.

[0112] Seeing this capability, the server tailors the SDP description tobe sent to the client, including the RTP Retransmission capability andthe SupportedAdaptationSupport capability. The SDP description is shownin FIG. 6. The server does not include the SDP attributes based on theUnsupportedAdaptationSupport, because it does not have support for it.The bold lines in the SDP description indicate the usage of the RTPRetransmission payload format and the support forSupportedAdaptationSupport.

[0113] By receiving this SDP description, the client knows that RTPretransmission will be used for the video component, but not for theaudio component. It also understands that UnsupportedadAptationSupportwill not be used and SupportedAptationSupport mechanism or capabilitywill be used for both audio and video media.

[0114] B. Signalling and Negotiation via a Possible Multimedia StreamingControl Protocol

[0115] In 3G PSS, RTSP protocol is used to control the multimediasession.

[0116] Let “x-rtxsupport” be a well-defined RTSP option tag, whichindicates RTP retransmission payload format is supported by the client.

[0117] Let “x-unsupportedadaptationsupport” be a well-defined RTSPoption tag, which is signalled in the RTSP message when supported by theclient. Assume that the mechanism or capability represented by this tagis not supported by the server.

[0118] Let “x-supportedadaptationsupport” be a well-defined RTSP optiontag, which is signalled in the RTSP message when supported by theclient.

[0119] The client is assumed to know the RTSP URL for the multimediasession.

[0120] The client sends a DESCRIBE request with the selection ofpreferred adaptation mechanisms or capabilities:

[0121] Client->Server:

[0122] DESCRIBE rtsp://foo/twister RTSP/1.0

[0123] CSeq: 1

[0124] Require: x-rtxsupport, x-unsupportedadaptationsupport,x-supportedadaptationsupport

[0125] The client uses the RTSP Require request header to signal thesupported adaptation mechanisms or capabilities.

[0126] In order for the server to successfully tailor the SDP accordingto the adaptation mechanisms or capabilities supported by the client,the client signals the adaptation mechanisms or capabilities supportedin an RTSP request prior to or at RTSP DESCRIBE method.

[0127] The server checks the RTSP request and sees that it can usex-rtpsupport and x-supportedadaptationsupport, but not usex-unsupportedadaptationsupport.

[0128] The server has two possible ways to respond:

[0129] Alternative 1:

[0130] Server sends RTSP 551 “Option Not Supported” Response, includingthe unsupported mechanisms or capabilities in the message body.

[0131] Server->Client

[0132] RTSP/1.0 551 Option not supported

[0133] CSeq: 1

[0134] Unsupported: x-unsupportedadaptationsupport

[0135] Client issues another DESCRIBE request with only the supportedmechanisms or capabilities:

[0136] Client->Server:

[0137] DESCRIBE rtsp://foo/twister RTSP/1.0

[0138] CSeq: 2

[0139] Require: x-rtxsupport, x-supportedadaptationsupport

[0140] Server responds with RTSP 200 OK message, also containing an SDPdescription as shown in FIG. 7.

[0141] Alternative 2:

[0142] Server sends an RTSP DESCRIBE response, containing unsupportedmechanism/capability information without RTSP 551 status response. TheRTSP DESCRIBE response is shown in FIG. 8.

[0143] The server uses RTSP Unsupported response header to signal theunsupported mechanism or the adaptation mechanisms or capabilities thatare not possible to use for the particular session, and uses theappropriate SDP attributes to signal the usage of the selectedadaptation mechanisms or capabilities.

[0144] When client receives the DESCRIBE response with the SDPdescription, it knows which set of adaptation mechanisms or capabilitiesare selected for usage in this particular session.

[0145] In the case that the client receives the SDP description fromanother source, e.g. via MMS, the client analyzes the SDP descriptionand find out the RTSP session URL. Then, it sends an RTSP DESCRIBErequest to signal and negotiate the adaptation mechanisms orcapabilities. The client can tailor the set of adaptation mechanisms orcapabilities by analyzing the MMS retrieved SDP description beforehand.This solves the confusion on the server side, because the server doesnot exactly know the content of the SDP description in such a usagescenario.

[0146] III. SRTP Usage in a Particular 3G PSS Session

[0147] Let the attribute “SRTPSupport”be defined in the RDF Schemavocabulary to signal the support of SRTP defined in draft-srtp-05 foraudio and video media.

[0148] Let the attribute “UnSupportedAdaptationSupport” be defined inthe RDF Schema vocabulary as an adaptation mechanism or capability,which is supported by the client, but not by the server.

[0149] Let the attribute “SupportedAdaptationSupport” be defined in theRDF Schema vocabulary as an adaptation mechanism or capability, which isalso supported by the server.

[0150] Let “x-srtpsupport” be a well-defined SDP attribute which isincluded in the audio and video (or the session-level for usage in bothmedia types) media section of the SDP when SRTP is supported.

[0151] Let “x-unsupportedadaptationsupport” be a well-defined SDPattribute which is included in the SDP (session or media level) whensupported.

[0152] Let “x-supportedadaptationsupport” be a well-defined SDPattribute which is included in the SDP (session or media level) whensupported.

[0153] A. Signalling and Negotiation via a Possible Capability ExchangeMechanism

[0154] The client sends an RTSP DESCRIBE request to the server with aURI pointing to the client capability information residing in acapability exchange server.

[0155] The server fetches the capability declaration of the client fromthe capability exchange server. The declaration includes a part for theclient-side streaming capabilities, as shown in FIG. 9. The bold linesin the declaration represent the adaptation mechanism supportcapabilities of the client. SRTPSupport, when TRUE, declares that theclient has the SRTP support for audio and video media components in aparticular session.

[0156] Seeing this capability, the server tailors the SDP description tobe sent to the client including the SRTP capability and theSupportedAdaptationSupport capability. The SDP description is shown inFIG. 10. The server does not include the SDP attributes based on theUnsupportedAdaptationSupport, because it does not have support for it.

[0157] The bold lines in the SDP description indicate the usage of theSRTP and the support for SupportedAdaptationSupport.

[0158] By receiving this SDP description, the client knows that SRTPwill be used for video and audio components. Client also understandsthat UnsupportedadAptationSupport is not going to be used andSupportedAptationSupport mechanism or capability will be used for bothaudio and video media.

[0159] B. Signalling and Negotiation via a Possible Multimedia StreamingControl Protocol

[0160] In 3G PSS, RTSP protocol is used to control the multimediasession.

[0161] Let “x-srtpsupport” be a well-defined RTSP option tag, whichindicates SRTP support on the client.

[0162] Let “x-unsupportedadaptationsupport” be a well-defined RTSPoption tag, which is signalled in the RTSP message when supported by theclient. Assume that the mechanism or capability represented by this tagis not supported by the server.

[0163] Let “x-supportedadaptationsupport” be a well-defined RTSP optiontag, which is signalled in the RTSP message when supported by theclient.

[0164] The client is assumed to know the RTSP URL for the multimediasession.

[0165] The client sends a DESCRIBE request with the selection ofpreferred adaptation mechanisms or capabilities:

[0166] Client->Server:

[0167] DESCRIBE rtsp://foo/twister RTSP/1.0

[0168] CSeq: 1

[0169] Require: x-srtpsupport, x-unsupportedadaptationsupport,x-supportedadaptationsupport

[0170] The client uses the RTSP Require request header to signal thesupported mechanisms or capabilities.

[0171] In order for the server to successfully tailor the SDP accordingto the mechanisms or capabilities supported by the client, the clientsignals the mechanisms or capabilities supported in an RTSP requestprior to or at RTSP DESCRIBE method.

[0172] The server checks the RTSP request and sees that it can usex-srtpsupport and x-supportedadaptationsupport, but notx-unsupportedadaptationsupport.

[0173] The server has two possible ways to respond:

[0174] Alternative 1:

[0175] Server sends RTSP 551 “Option Not Supported” Response, includingthe unsupported mechanisms or capabilities in the message body.

[0176] Server->Client

[0177] RTSP/1.0 551 Option not supported

[0178] CSeq: 1

[0179] Unsupported: x-unsupportedadaptationsupport

[0180] Client issues another DESCRIBE request with only the supportedmechanisms or capabilities:

[0181] Client->Server:

[0182] DESCRIBE rtsp://foo/twister RTSP/1.0

[0183] CSeq: 2

[0184] Require: x-srtpsupport, x-supportedadaptationsupport

[0185] Server responds with RTSP 200 OK message, also containing an SDPdescription as shown in FIG. 11.

[0186] ALTERNATIVE 2:

[0187] Server sends an RTSP DESCRIBE response, containing unsupportedmechanism/capability information without RTSP 551 status response. TheRTSP DESCRIBE response is shown in FIG. 12.

[0188] The server uses RTSP Unsupported response header to signal theunsupported mechanism or the adaptation mechanisms or capabilities thatare not possible to use for the particular session, and uses theappropriate SDP attributes to signal the usage of the selectedadaptation mechanisms or capabilities.

[0189] When client receives the DESCRIBE response with the SDPdescription, it knows which set of adaptation mechanisms or capabilitiesare selected for usage in this particular session.

[0190] In the case that the client receives the SDP description fromanother source, e.g. via MMS, the client analyzes the SDP descriptionand find out the RTSP session URL. Then, it sends an RTSP DESCRIBErequest to signal and negotiate the adaptation mechanisms orcapabilities. The client can tailor the set of adaptation mechanisms orcapabilities by analysing the MMS retrieved SDP description beforehand.This solves the confusion on the server side, because the server doesnot exactly know the content of the SDP description in such a usagescenario.

[0191] In sum, the present invention provides a method of signaling andnegotiation between a client and a server in a multimedia streamingservice system regarding the adaptation of a data delivery process. Theprocedure for the signaling and negotiation can be illustrated by FIG.13. As shown in the flowchart in FIG. 13, in order to negotiate anadaptation mechanism or capability, the client signals to the server aplurality of attributes to the client at step 110. These attributes arethose of the adaptation mechanisms or capabilities implemented by theclient. The attributes are included either in client's capabilityprofile defined for a capability exchange mechanism, or in themultimedia streaming control protocol defined for the control of thestreaming session. At step 120, the server obtains the attributes fromthe capability profile or the multimedia streaming control protocol, andselects a subset of these attributes. Based on the selected attributes,the server tailors a multimedia session description and sends thedescription to the client at step 130. Based on the session description,the client knows the attributes selected by the server. At step 140, theclient accepts the adaptation mechanisms or capabilities defined by theselected attributes at default. The signaling and negotiation method,according to the present invention, can be implemented in an AVPT usage,an RTP Retransmission Payload Format usage or an SPTP usage in aparticular 3G PSS session.

[0192] It should be noted that the method of signaling and negotiation,according to the present invention, can also be initiated by the server,as illustrated in the flowchart shown in FIG. 14. As shown, the serverindicates to the client, at step 210, the adaptation mechanism orcapability without client's initiation. In this case, there is noindication of the adaptation mechanism or capability from the clientside, but from the server side. After obtaining the indication from theserver, the client uses a well-defined attribute in the RSTP response toindicate, at step 220, its support for that capability to the server.

[0193] Thus, although the invention has been described with respect to apreferred embodiment thereof, it will be understood by those skilled inthe art that the foregoing and various other changes, omissions anddeviations in the form and detail thereof may be made without departingfrom the scope of this invention.

What is claimed is:
 1. A method for signaling and negotiation between aclient and a server in a multimedia streaming service, wherein aplurality of adaptation mechanisms or capabilities for use in theservice for data delivery are supported by the client, each adaptationmechanism or capability having an attribute, said method comprising: theclient providing information indicative of the attributes defining theadaptation mechanisms or capabilities that are supported by the client;the server selecting one or more of the attributes based on the providedinformation; and the server providing further information indicative ofthe selected attributes so as to allow the client to know the one ormore adaptation mechanisms or capabilities defined by the one or moreattributes selected by the server.
 2. The method of claim 1, wherein theclient provides the information via a capability exchange mechanism. 3.The method of claim 1, wherein the client provides the information via amultimedia streaming control protocol.
 4. The method of claim 1, furthercomprising the server providing indication of a capability to the clientprior to the client providing information.
 5. A method for signaling andnegotiation between two parties including a client and a server in amultimedia streaming service, wherein a plurality of adaptationmechanisms or capabilities for use in the server for data delivery aresupported by the client, each adaptation mechanism or capability havingan attribute, said method comprising: providing by one of the twoparties to the other of the two parties information indicative of one ormore adaptation mechanisms or capabilities; and conveying a message fromsaid other party to said party, in response to the information,acknowledging supporting of said one or more adaptation mechanisms orcapabilities.
 6. The method of claim 5, wherein said one party is theserver and the other party is the client, and wherein the clientacknowledges support by using the attributes defining said one or moreadaptation mechanisms or capabilities in the responding message.
 7. Themethod of claim 5, wherein said one party is the client and the otherparty if the server, and wherein the client provides a plurality ofattributes; and the server selects one or more of the providedattributes based on the provided information for acknowledging thesupport.